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Experimental testing is an important aspect of validating complex integrated safety- 
critical aircraft technologies. The Airborne Subscale Transport Aircraft Research 
(AirSTAR) Testbed is being developed at NASA Langley to validate technologies under 
conditions that cannot be flight validated with full-scale vehicles. The AirSTAR capability 
comprises a series of flying sub-scale models, associated ground-support equipment, and a 
base research station at NASA Langley. The subscale model capability utilizes a generic 
5.5% scaled transport class vehicle known as the Generic Transport Model (GTM). The 
AirSTAR Ground Facilities encompass the hardware and software infrastructure necessary 
to provide comprehensive support services for the GTM testbed. The ground facilities 
support remote piloting of the GTM aircraft, and include all subsystems required for 
data/video telemetry, experimental flight control algorithm implementation and evaluation, 
GTM simulation, data recording/archiving, and audio communications. The ground 
facilities include a self-contained, motorized vehicle serving as a mobile research 
command/operations center, capable of deployment to remote sites when conducting GTM 
flight experiments. The ground facilities also include a laboratory based at NASA LaRC 
providing near identical capabilities as the mobile command/operations center, as well as the 
capability to receive data/video/audio from, and send data/audio to the mobile 
command/operations center during GTM flight experiments. 


1.0 Introduction 

The Single Aircraft Accident Prevention Project of the NASA Aviation Safety and Security Program (AvSSP) 
is developing technologies to reduce aircraft accidents resulting from loss of vehicle control as well as failures [1]. 
Loss-of-control is among the highest accident categories across all vehicle classes for both the number of accidents 
and the number of fatalities. Although many loss-of-control accidents include system or component failures as a 
primary or secondary causal factor, aircraft accidents due to failures have also resulted in a significant number of 
fatal accidents that can be listed as a separate category. The research goal is to make revolutionary enhancements to 
aviation safety by improving the ability to monitor vehicle health and to safely manage fault and failure conditions 
in aircraft systems, and to prevent and recover from aircraft loss-of-control conditions. The scope of research 
encompasses all aspects of the hardware and software life cycle, from analysis of design specifications, 
implementation and verification, to validation methods to ensure design correctness, fault tolerance, and functional 
integrity in the operating environment. A validation process is currently under development that includes a 
coordinated approach to analysis, simulation, and experimental test methods [2] - [3]. Experimental testing includes 
the Airborne Sub-scale Transport Aircraft Research (AirSTAR) testbed capability that is being developed to validate 
technologies that cannot be flight validated with full-scale vehicles. Dynamics modeling and simulation 
technologies for adverse and upset flight conditions require flight validation at extreme and upset conditions, as well 
as unusual flight maneuvers within the normal flight envelope. Detection and identification technologies for failures 
and damage under adverse and upset flight conditions will require flight validation under normal, extreme, and upset 
flight conditions. Upset recovery algorithms, reconfigurable control for failures and damage, and adaptive outer- 
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loop autopilot and trajectory management algorithms for damage and failure conditions will also require flight 
validation under extreme and upset flight conditions. These validation requirements are unsuitable for full-scale 
flight validation due to high risk, but can be satisfied using sub-scale models. 

Use of a Remotely Piloted Vehicle for conducting flight tests to validate control upset prevention and recovery 
technologies (including modeling and control methods for characterizing and recovering from upset conditions) will 
require a robust and reliable ground support system for pilots and researchers. This paper describes the ground 
facilities being developed to support the NASA Langley Research Center AirSTAR testbed. The AirSTAR aircraft 
is a 5.5% dynamically scaled, remotely piloted, Generic Transport Model (GTM) which will be used to conduct 
flight test research experiments pertaining to dynamics modeling and control beyond the normal flight envelope [4] 
- [5]. Figure 1 shows a functional diagram of the basic GTM-Ground Facilities (GTM-GF) architecture. 
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Figure 1. Block Diagram of Ground Facilities Functionality 

The fundamental purpose of the GTM-GF is to provide the apparatus to accomplish the following: 


• Permit research pilots to control the GTM; 

• Receive, process, record and transmit GTM telemetry data; 

• Display information to pilots, researchers, systems engineers and observers; 

• Provide voice communications for experiment participants and observers; 

• Provide data processing systems capable of computing control parameters on the ground to augment pilot 
control and/or remotely drive aircraft control surfaces; 

• Provide real-time GTM simulation for training, testing and experiment reproduction. 

The GTM Ground Facilities are designed to align with the overall development of the NASA Langley Research 
Center Systems and Airframe Failure Emulation, Testing and Integration (SAFETI) Research Laboratory [6]. The 
SAFETI Lab is being developed for validation testing of AvSSP technologies and to support long-term Aviation 
Safety and Security Program experimental research goals and objectives. 

The GTM-GF will ultimately be the conjugation of two separate resources [7] - [8]: (1) the Mobile Operations 
Station (MOS) - a self-contained, motorized vehicle serving as a mobile research command/operations center, 
capable of deployment to remote sites when conducting GTM flight experiments [9]; and (2) the Base Research 
Station (BRS) - a laboratory based at the NASA Langley Research Center providing near-identical capabilities as 
the MOS. Figures 2 and 3 below outline the basic differences between hardware systems in the BRS and the MOS. 
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Figure 2. MOS Hardware Systems Overview 



Figure 3. BRS Hardware Systems Overview 


The overall GTM-GF architecture will also include the capability to link the BRS and MOS (data, video and voice) 
during GTM flight experiments. The BRS will be used for experimental software development and testing. The 
BRS also includes a “hot bench” work area which will accommodate hardware-in-the-loop test and evaluation with 
the GTM. 

This paper provides a detailed description of the AirSTAR testbed ground facilities being developed at the 
NASA Langley Research Center. Section 2 describes the major hardware systems. Data archiving and playback is 
discussed in Section 3. Section 4 describes the Audio/Video Systems. The satellite-based data/video link is 
described in Section 5. A description of the GTM Video Tracking System is provided in Section 6. The Mobile 
Operations Station is described in Section 7. Section 8 discusses the Safety Pilot Station. Major software 
components are described in Section 9. A summary and some concluding remarks are provided in Section 10. 
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2.0 Major Hardware Subsystems 


Major hardware subsystems include the air- ground data link, computational resources, and user interfaces. 

Each of these subsystems is discussed in the following subsections. 

2.1 Air-Ground Datalink 

Communications between the AirSTAR aircraft and the GTM-GF are via a duplex serial data link using 
microwave RF transceivers, with a separate safety-pilot backup command RF link (ref section 8.0). The current 
experiment for which the GTM-GF is being configured will conduct flight maneuvers within a test range airspace 
volume of approximately 2 cubic statue miles (2 miles x 1 mile x 1 mile). To maintain effective telemetry 
communications coverage, the GTM-GF will employ a directionally-tracked, circularly-polarized antenna system. 
Analysis of the anticipated RF budget (involving transmitter powers, receiver noise floors, and antenna gains) 
supports the desired operation of the microwave links to slant ranges up to 2 statue miles with power margins in 
excess of 15 decibels. The AirSTAR telemetry system evolved from an air-to-ground datalink system developed by 
Microbotics Inc., and utilizes a proprietary encoding scheme based on the IRIG-106 standard. The telemetry system 
is comprised of a custom built airborne unit installed in the GTM and a custom built ground unit interfaced to the 
GTM-GF [10] -[12]. 

Telemetry Airborne Unit (TA U) 

The TAU’s primary function is to perform the multiplexing and de-multiplexing of the telemetry data for the GTM’s 
on-board instrumentation and control systems. The on-board TAU is microprocessor-based, and incorporates 
hardware to assist in aircraft operations and instrumentation, including signal interface boards, safety switch, and 
power supplies. The TAU acquires data from various sensors aboard the GTM, including transducers indicating 
flight surfaces position, angle-of-attack probes, engine control units (ECU), MIDG 11^, battery status, and employs 
a ‘Flight Controller’ module to multiplex this data for the air-to-ground telemetry stream. Conversely, the ‘Flight 
Controller’ module is used to de-multiplex the ground-to-air telemetry stream, distributing commands to GTM 
subsystems, including the flight surface servos. Additionally, video from the GTMs’ nose camera will be 
transmitted via the RF link to the ground. 

Telemetry Ground Unit (TGU) 

The TGU’s primary function is to perform the multiplexing and de-multiplexing of the telemetry data for GTM-GF 
client computers, and is housed in a standard 19” rack-mountable enclosure. The TGU interfaces to the GTM-GF 
computing system via four asynchronous serial (RS-422) ports that are used to receive flight data from the GTM and 
transmit control surface servo commands to the GTM. These ports, each running at 115200 baud, parse the 
telemetry data stream as shown in Tables 1 and 2. 


Table 1: Ports for Telemetry from GTM to GTM-GF (Downlink) 


(Downlinked on S-band frequency 2240.5 MHz) 

port 0 

16 Analog signals per port (48 
total) 

8 digital inputs each portO and 
portl; 16 digital inputs port2 
(32 total) 

1 serial stream each portO and 
portl for engine control units 
(2 total) 

port 1 

includes surface positions, 

port 2 

angles of attack, air speed, 
battery status, etc 

includes system status codes, 
gear up/down, etc. 

codes from left and right 
ECU’s 

port 3 

1 serial stream from the MIDG II inertial package 


Additionally, the TGU receiver uses an RF sideband to receive video from the GTM nose camera, with this received 
video signal present at a rear-panel BNC connector. 


ft The MIDG II is a product from Microbotics Inc. which outputs GTM rotational rates, attitude, accelerations, GPS velocity and 
position, inertial navigation velocity and position (filtered velocity and position from GPS measurements and inertial 
measurements), magnetometer data, and GPS satellite data, all in a very small, lightweight package. 
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Table 2: Ports for Telemetry from GTM-GF to GTM (Uplink) 


(Uplinked on L-band frequency 1835.5 MHz) 

port 0 

16 Pulse Width Modulated (PWM) signals each (32 total) 
servo commands 

port 1 

port 2 

16 digital output level commands for the Microbotics Servo Switch/Controller (SSC)JJ 
This message is ignored at the airborne unit if SSC auxiliary channel defined as a digital input 

port 3 

RTCM DGPS corrections to GTM 


The rate for GTM-to-Ground telemetry (excluding MIDG II) data is configurable within a range of 200 to 250 Hz, 
and for AirSTAR operations is set to 216Hz to accomplish the required data rates. The MIDG II provides INS data 
at 50Hz. Consequently, a ‘subframe’ period of approximately 4.6ms is established for parameters downlinked on 
ports 0-2, while a ‘major frame’ period of 20ms is established for MIDG II data downlinked on port 3. 

Calculations indicate that downlink data from ports 0-2 (40 Bytes per port) will require 2.77ms (60% of a minor 
frame) to arrive at GTM-GF computers. MIDG II INS data downlinked on port 3 (160 Bytes) are estimated to 
require approximately 1 1.1 1ms (2.37 subframes = 55% of a major frame) to arrive at GTM-GF computers. 

Calculations indicate that uplink data to ports 0-2 (< 38 Bytes per port) will require 2.64ms (57% of a minor frame) 
to be received into the GTU. Thus, GTM-GF computing systems must process all parameters within an estimated 
20ms - (1 1.1 1ms + 2.64ms) = 6.25ms. 

2.2 Computational Resources 

Scaled flight research has demanding data system frame timing deadlines that require the deterministic program 
execution rate provided by a real-time operating system (RTOS). The GTM-GF computing system is capable of 
accomplishing three primary tasks: 

1. receiving telemetered GTM state data (e.g. sensor outputs, discretes, etc.), converting these data to 
calibrated engineering units in real-time, and transmitting control-surface and engine commands and other 
required state data to the GTM via the telemetry system; 

2. processing, in real-time, researcher-provided algorithms, including 

• flight control algorithms to compute control- surface and engine commands in response to pilot 
inputs and/or aircraft state data; 

• failure detection and isolation (FDI) algorithms, upset recovery algorithms, and guidance 
algorithms; 

3. providing real-time, hardware-in-the-loop (HIL) simulation of the GTM, including the capacity for 
integrating synthetic vision display components and terrain databases for flight control by the research 
pilot. 

Non-time-critical computing tasks such as generation of user displays are managed by Intel® /Windows®-based 
Personal Computers. 

Time critical computing tasks will be managed by the dSPACE® computing platform. The dSPACE Real-Time 
Operating System (RTOS) was chosen to control the GTM while flying research control laws. dSPACE, which 


The Microbotics Servo Switch/Controller (SSC) is a highly configurable, multiplexing switch for servo command signals. It 
allows the dynamic selection of several sources of pulse signals for servos. Pulse sources include asynchronous serial 
communication packets from a control computer, pulse signals from a conventional RC receiver or other servo pulse generator, 
and user definable constant signals. 
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integrates target processor hardware, C code, analog and digital input/output, and control law block diagrams, was 
chosen because it was based on Matlab® and Simulink® products developed by The Mathworks, Inc. The dSPACE 
platform is a good fit with existing commercial aircraft simulations based on tools developed by The Mathworks, 
Inc. Matlabs’ plotting and scripting features facilitate manipulation of wind tunnel data sets to obtain aerodynamic 
data parameters and verify control algorithms against check data. The graphical data flow characteristics of 
Simulink are a close fit to the characteristics of control law diagrams in aerospace documentation. The use of 
dSPACE reduces the amount of custom programming necessary to integrate the aircraft telemetry subsystems. The 
commonality between dSPACE and the simulation tools facilitates exercising the software at each stage of 
development with a realistic execution environment, and rapidly testing various HIL configurations. 

2.3 User Interfaces 

GTM-GF operations will be conducted by personnel located at three primary work areas: the Flight Research 
Station, the Operations Command Station, and Operations Engineering Station. Each of these work areas are 
described below. 

2.3.1 Flight Research Station ( FRS ) 

The GTM pilot and research projects’ principal investigator (PI) will be located in the FRS. This station 
provides the means to fly the GTM manually or automatically by engagement of a researcher-provided autopilot 
flight control system implemented in the dSPACE computer. The FRS will provide all necessary pilot controls and 
a variety of displays for the pilot and PI. Figures 4 and 5 show photographs of the FRS and BRS hardware, 
respectively. 



Figure 4. Flight Research Station in BRS 



Figure 5. Photograph of BRS subsystem hardware - note view into “hotbench” area 
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The display layout for the FRS is shown in Figure 6. 
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Figure 6. Display Layout for the Flight Research Station 


Displays generated for the FRS will include the Primary Research Pilot Display, the Navigation Display, as well as 
other displays. These displays are described below. 

GTM Primary Research Pilot Display (PD) 

The PD will serve as the pilot’s primary indicator of flight information, incorporating display elements typically 
presented as part of the Primary Flight Display (PFD) found on modem commercial and business aircraft. The PD 
provides GTM flight information, including but not limited to, attitude and heading, airspeed, altitude, track angle, 
flight path angle, load factor, angle-of-attack, and sideslip angle. The PD can also be configured to integrate 
synthetic terrain or nose camera video into its background, and provide programmable primary display symbology 
for the research pilot. Figure 7 shows an example of a potential PD display format with a synthetic vision 
background. 



Figure 7. Prototype GTM Primary Research Pilot Display 
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GTM Navigation Display ( ND ) 

The ND will serve as the pilot’s primary indicator of situational flight information, incorporating display elements 
typically presented as part of the Navigation Display found on modern commercial and business aircraft. The ND 
will serve as the pilot’s primary indicator of the GTMs’ location during flight tests, and can be configured to provide 
a variety of indicators and alerts, including a test range map with boundaries, runway depiction, vehicle track angle, 
desired horizontal path waypoints, and predicted path in a specified time period. Figure 8 shows an example of a 
potential ND format. 





Flight Path 
Predictor Noodle 


Figure 8. Prototype GTM Navigation Display for the Research Pilot Station 


Other Displays 

In addition to the Primary Research Pilot Display and Navigation Display, the GTM-GF provides for the generation 
and distribution of appropriate graphical displays for all flight test personnel including: 

• any available GTM state data and/or experiment parameters 

• camera video (e.g. tracking system, GTM nose camera, other on-board and ground-based cameras) 

• any available health and/or status information associated with GTM and GTM-GF subsystems (e.g. on- 
board battery power, TM link signal strength, weather data, etc.) 


2.3.2 Operations Command Station (PCS) 

The Flight Test Director, who has the responsibility of coordinating all flight test related activities, and another 
researcher will be located in this area. The OCS will be provided with six display units, and the capability to 
configure and select among all available video sources as desired. The OCS will provide for monitoring and control 
of all audio communications between flight test participants. The OCS will also provide the capability to conduct 
researcher-specific activities such as: 

• selecting test parameters for display; 

• setting test parameters that control test conditions; 

• setting simulated fault conditions; 

• performing pre/post-flight analysis of recorded flight data, including running the GTM simulation. 

Figures 9 and 10 show the general layout for the OCS and a photograph, respectively. 
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Figure 9. General Layout for Operations Command Station and Operations Engineering Stations 



Figure 10. Photograph of Operations Command Station and Operations Engineering Stations in BRS 


2.3.3 Operations Engineering Station (OES) 

Hardware and software support engineers will be located in this area. These support engineers will be 
responsible for monitoring and maintaining GTM-GF hardware and software subsystems during flight test 
operations. The OES will be similar in appearance to the OCS, and will have keyboard and mouse access to all 
GTM-GF computers, as well as the satellite terminal and data network (see Figures 9 and 10). 


3.0 Data Archiving and Playback 

Integral to the mission of AirSTAR scientific research is data collection and storage. The success of post-flight 
analysis hinges on the accurate and properly registered capture of GTM state parameters and GTM-GF process 
elements. With valid and complete data the stated goals of investigating new aerodynamic technologies can be more 
fully realized. The GTM-GF is equipped with an Asynchronous Real-Time Multiplexer and Output Reconstructor 
(ARMOR) subsystem. This system element consists of an Apogee Labs Model 4800 Digital Recorder Unit (DRU) 
interfaced to an Apogee Labs MITC FALCON Model 4303 Multiplexer /Demultiplexer. The multiplexing system 
merges multiple data sources, including GTM PCM telemetry data, 1 0 Mb/s Ethernet, voice, time code signals and 
video into a composite stream for digital recording. A plug-in Recorder Interface Module (RIM) provides a link to 
the DRU, which provides a recording interface to RAID 1 hard drives, with 90 Mb/s data transfer rate. 
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This ARMOR system is configured to provide playback of all recorded GTM flight data parameters, physical 
camera video outputs, synthetic display video outputs, audio loops, and UTC time tag information, with partial or 
complete data reconstruction, including downlink/uplink telemetry to the GTM, camera video, audio loops, and 
master UTC information, allowing new real-time simulations to execute using recorded state data. Partial 
reconstruction provides the capability to perform engineering tests of the air-ground system, and debugging of 
anomalous behavior. 


4.0 Audio/Video Systems 

The GTM-GF Audio System is described in Section 4.1 and the Video System is described in Section 4.2. 

4.1 GTM-GF Audio System 

The GTM-GF provides the communications infrastructure to allow all key participants in GTM flight test 
activities to maintain voice contact. The heart of the intercom system is the Clear-Com Inc. MicroMatrix® 24- 
channel digital intercom system. Onboard slots for interface cards permit seamless interfacing with telephones, two- 
way radios, party-line intercoms, and wireless belt packs. Set up of point-to-point communications, groups, 
monitoring lines, and “virtual” party lines for all flight test participants is accomplished using interactive and menu- 
driven Windows-based software. The intercom master control system is operated by the flight test director during 
GTM flight test operations. 

4.2 GTM-GF Video System 

The GTM-GF provides the video hardware infrastructure to allow all video camera output signals and all computer 
generated displays to be amplified and split as necessary for distribution to key participants in GTM flight test 
activities. The heart of the GTM-GF video distribution system is Extron Electronics’ CrossPoint Plus 24x24 matrix 
video switch, an ultra- wideband analog RGBHV matrix switcher, capable of distributing any of 24 video inputs to 
any combination of 24 video outputs simultaneously. Additionally, a Crestron Inc. MC2E controller is interfaced to 
the video matrix switch, permitting users to operate the matrix switch from the Flight Research Station, Operations 
Command Station or the Operations Engineering Station. 


5.0 Satellite-based Data/Video Link 

In order to provide the capability to monitor MOS GTM flight test activities at the Base Research Station 
located at Langley Research Center, a satellite backbone transmission system will be utilized to (1) transmit GTM 
telemetry state data, optical video and voice communication from MOS to BRS, and (2) transmit desired support 
data and voice communications from BRS to MOS. The major communications system elements comprising the 
satellite system consist of a fixed base station satellite dish, a deployable remote station satellite dish, and the 
necessary interface equipment. The Base and Remote Stations employ a satellite backbone transmission system 
augmented by data, video and voice communication facilities, and an Internet Protocol (IP) routing system. The IP 
routing system provides for multiple communication transmission types and automatic routing path requirements. 
The base station consists of a 2.4 - meter dish antenna and rack mounted satellite, video, audio, and routing 
equipment. The remote station consists of a 1 .2-meter dish antenna contained in two field carrying cases, a field case 
for the antenna RF equipment, and satellite, video, audio, and routing equipment mounted in a separate field 
carrying case. The remote station is further augmented by a wireless video and audio transmission system, which 
provides for line of sight transmission of tracking video and voice communications from the Video Tracking Station. 

The satellite system will rely on an Immeon network communications link. The Immeon System is a joint 
venture between Loral Skynet and ViaSat. The Immeon System is unique in that it can supply connectivity between 
satellite stations via a satellite, in this case Telstar IV, on an as needed basis. This lowers satellite usage costs. The 
connection service is available on a 24 hours-per-day, 7 days-a-week basis and is provided by a teleport and network 
control system located in Atlanta, GA. The system communications are based on Internet Protocol (IP) addressing; 
fully automating all routing of video, data, and voice communications within the system. This is accomplished by 
using commercial off-the-shelf network routing equipment. The routing equipment will utilize telephony- switching 
equipment to accommodate voice communications. The camera optical data will be processed by a video encoder at 
the MOS site for satellite transmission, and translated back to video at the BRS site for display purposes. 
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The satellite system will utilize two carrier frequencies within the U.S. Ku band, between 14.0 and 14.5 GHz. As 
this frequency is in a non-federal government band, it was coordinated through the Federal Communications 
Commission (FCC) and is subject to FCC jurisdiction. Consequently, there is a one-year duration of use with 
renewal options. 

The 2.4Meter fixed dish at the BRS will employ an 8 Watt power amplifier to achieve a 1.0 Mbps (1 Mbps = 
1,048,576 bits-per-second) uplink data rate. The 1.2Meter deployable dish at the MOS will employ a 25Watt power 
amplifier to achieve a 2.048Mbps uplink data rate. 

As the Telstar IV system is comprised of satellites located 22,000 miles above the equator in geosynchronous 
Earth orbit, closed-loop operations involving GTM control inputs generated at the BRS will incur a 0.5 sec 
(minimum) latency. For this reason, remote piloting of the GTM from the BRS is not currently planned. 


6.0 Video Tracking System 

In order to provide the capability to monitor the GTM in flight, a ground-based video tracking system will be 
deployed with the MOS and will track the airborne vehicle using cameras and electronic equipment. The tracking 
video could be used by safety pilots to help fly the GTM to the MOS if a takeover is required when the GTM is 
beyond the line-of-sight. This video tracking system will be augmented by a wireless video and audio transmission 
system, to provide for transmission of tracking video and voice communications from the video tracking system to 
the MOS. The trackers’ limited maximum slew rate (6 degrees per second estimated) dictates that the tracker be 
setup at a location offset one to two statute miles from the MOS, and within line-of-sight of the MOS wireless video 
receiver. This location will be called the Tracking System Station (TSS), and an operator will be required to operate 
the system. The TSS will employ a two-way communication link to the intercom master control system located at 
the Operations Command Station. The tracking system is capable of receiving GTM GPS/DGPS position data in 
order to augment the system’s ability to maintain GTM tracking lock, and tracking video will be transmitted to the 
MOS for display as desired by users at the various operations stations. 

The GTM Video Tracking System is a portable and fully self-contained system, designed and constructed by 
Celestial Computing Corp. The tracker can be disassembled and transported in six travel cases, each case having a 
maximum allowable weight of 120 pounds. The tracking system is comprised of a portable pier tripod assembly, 
supporting optical acquisition lenses and video cameras mounted on a motorized 2-axis gimballed system. The 
system includes an Automated Telescope Startup Unit (ATSU) with precision home and park positions to .001 
degrees, with electronic Periodic Error Correction (PEC) and Charge Coupled Device CCD port for astronomical 
self-guiding, and is capable of computerized full-sky "Go-To" pointing, which can be set up for remote or local 
operation. The tracker is capable of equatorial and alt-azimuth alignment and tracking, with adjustable slew speeds 
up to 6.0 degrees per second. This hardware is interfaced to a PC running customized software, which sends 
commands to the gimbal system to maintain tracker lock on the GTM. 


7.0 Mobile Operations Station (MOS) 

The Mobile Operation Station is a deployable remote laboratory site that will be employed as the central 
research and command center for GTM research flight operations. In addition to all of the hardware and software 
components utilized in the BRS, the MOS contains the ancillary support subsystems required for operation in the 
field, including, power generator, Un-interruptible Power Supply (UPS) back-up subsystem, restroom facility, 
kitchenette, small meeting/work area, walk-on roof with safety rails, leveling jacks, and a self- stowing, deployable 
side awning. In addition to all interfaces available in the BRS, the MOS provides external power and data interfaces 
for additional subsystems, including, Safety Pilot Station, TSS video modem and Flight Line video camera, wireless 
transmitter for GPS data, VHF and cellular communications devices, LAN/intemet, 1.2 meter portable satellite dish, 
and 120 VAC “Shore” power feeds. 

The GTM MOS is built on a Freightliner® chassis and has the following specifications: 

• GVWR- up to 54,000 lbs.; 

• Length - 40 feet; 

• Rear Axle - Tandem, up to 40,000 lbs.; 

• Wheelbase - 290”; 

• Engine: CAT C7, 330 Hp. 
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The vehicle’s mission goal of providing a self-contained mobile research laboratory environment defines the design 
and minimum performance standard requirements of the Aft Body area. The Aft Body area is a self-contained/self- 
supporting laboratory consisting of four (4) sectioned off areas that will provide support to the three (3) users 
operations stations, four (4) full size equipment racks, two (2) half size equipment racks, and a Galley with a kitchen 
and lavatory area. Figure 1 1 shows the MOS floor plan. 



Figure 11. Mobile Operations Station Floor Plan View 


8.0 Safety Pilot Station 

In recognition of the fact that research flight will be increasingly dynamic in nature and will seek to set up high- 
risk/off-nominal (e.g. large angle-of-attack and sideslip) flight conditions it is deemed necessary to retain the role 
and inputs of a conventional R/C pilot towards enhancing overall mission safety. This capability to host a secondary 
controller, referred to as the safety pilot, has the following attributes. 

• The safety pilot is located externally to the MOS vehicle to provide a line-of-sight view of the GTM so as to 
afford direct observation of craft attitude when possible. If takeover is required when the GTM is beyond the 
line-of-sight, the safety pilot will use the nose camera video, tracker camera video, or a combination of the 
videos to fly the GTM back into line-of-sight. 

• The safety pilot inputs originate from a conventional handheld R/C transmitter that is configured to 
continuously emanate a special safety channel signal. 

The avionics of the GTM aircraft are engineered to receive the safety channel signal for the purpose 
of discriminating among four flight control cases: 

> ground research pilot inputs for advanced/general experiment conditions; 

> ground safety pilot inputs for basic/aborted experiment conditions; 

> onboard return-to-home autopilot inputs; 

> onboard range-safety inputs for abnormal/terminated flight conditions. 

• The safety pilot has a dedicated two-way audio communication channel with the Flight Test Director Station 
and the Research Pilot Station. 

Figure 12 illustrates how the Safety Pilot Station interfaces to the MOS. 
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Figure 12. Safety Pilot Station Interfaces 


9.0 Major Software Components 


The GTM-GF system network architecture is shown in Figure 13. 
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Figure 13. GTM Ground Facilities System Network Architecture 


The major software components will be contained within eight PCs and a Real-Time Simulation Computer 
(dSPACE), shown in Figure 13. There are three broad components of the overall GTM-GF software architecture, 
the simulation, the displays, and the networking component for both the BRS and the MOS. These are discussed in 
Sections 9.1 and 9.2. 
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9.1 Simulations 


The GTM simulation is capable of being executed in both the BRS and the MOS, and will acquire pilot and 
researcher input signals and generate six Degree of Freedom (6DOF) flight dynamics and sensor data, and emulate 
the GTM down-link telemetry stream. The simulation will run on a Personal Computer (PC) platform with the 
Windows operating system, using the Matlab/Simulink programming tools. The GTM simulation is referred to, in 
this document, as the Flight Dynamics Model (FDM), and will operate in three distinct configurations: 

• Personal Computer (FDM-PC), standalone, near real-time operation, on one or more PCs; 

• Piloted Simulation (FDM-PSIM), real-time simulated operation on the dSPACE platform; 

• Hardware In the Loop (FDM-HIL) real-time operation simulation on the dSPACE platform. 

Each of these configurations is discussed below. 

FDM-PC 

The FDM-PC is a standalone Matlab/Simulink simulation operating in near real-time on a Windows -based PC 
platform. The program is configured to receive input from a selection of flight controller hardware, send flight 
parameter information to a selection of graphical visual display programs, and send emulated telemetry sensor and 
flight information to an Ethernet port in User Datagram Protocol (UDP) packets to support development and testing 
of GTM Ground Facilities software. This setup is shown below in Figure 14. 



Research 

Support 

Systems 




Figure 14. FDM-PC Configuration 


FDM-PSIM 

The FDM-PSIM operates on the dSPACE system without I/O to the GTM. This setup will receive controller input 
signals from the Research Pilot Station interfaced to the dSPACE system. Simulated telemetry data will be output 
as a UDP format and distributed through the Ethernet bus for display generation and archiving. This setup is shown 
below in Figure 15. 
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Figure 15. FDM-PSIM Configuration 


FDM-HIL 

The FDM-HIL operates with the GTM through the dSPACE platform. This setup receives controller input signals 
from the Research Pilot Station through dSPACE input ports. It will receive telemetry signals from GTM sensors 
through dSPACE RS-422 serial input ports, and outputs command signals to the GTM telemetry system through 
dSPACE RS-422 serial output ports. Additionally, all telemetry data (uplink and downlink), and aircraft surface 
position commands from the pilot controls will be output over Ethernet through the support PC for archiving and 
display generation. The simulation will have an option for archive playback of the GTM states and controls using 
information obtained from the GTM as a means for testing the FDM simulation fidelity. This setup is shown below 
in Figure 16. 



Figure 16. FDM-HIL Simulation Configuration 
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9.2 Networking and Displays 

Networking is an Ethernet application for distributing telemetry and control data from the control computer to 
all other computers and devices involved in the ground facilities (ref. figure 13). It is a self-contained application, 
but is used within the dSP ACE-based Simulink applications to accomplish data output to the other systems of the 
ground facilities. 

The displays will be generated by several independent software applications, which render synthetic terrain, 
GTM images, and informational graphics. These include synthetic vision underlays, primary and navigation display 
symbology, and standalone status displays. The networking applications used for displays are derived from work 
done for NASA’s Synthetic Vision research project. The Synthetic Vision-based applications developed for the 
GTM-GF are comprised of three major components: the Message Manager, the Data Server and the Display 
Manager. Each of these components is described briefly below. 

• Message Manager - the Message Manager receives the data streams from the GTM telemetry system, 
repackages this information, and sends it to the Data Server. This repackaging process is necessary since 
the amount of data and update rate of the data from the model can vary; however, the Data Server requires 
complete messages at a pre-defmed rate. 

• Data Server - the Data Server receives data from the Message Manager, performs any necessary post- 
processing on the data, and places the data into the appropriate computers’ memory. Post-processing of the 
data may consist of unit conversion (i.e., convert the data from micro-volts measured by the GTM’s sensors 
to units that are more appropriate for creating and updating the displays). The Data Server also has the 
ability to record the data that it receives. 

• Display Manager - the Display Manager reads the computers’ memory to retrieve all of the data that is 
required to produce the desired displays. These displays include the Primary Flight Display (PFD), backup 
PFD, Navigation Display (ND), and all of the research displays. 

The Message Manager is installed only on the computer that links with the GTM telemetry downlink data. The Data 
Server and Display Manager, however, are installed on all of the computers that generate displays. 


10.0 Concluding Remarks 

The GTM-GF is currently being developed and configured to support the experiment “Aerodynamic Model 
Validation For Upset Conditions”. This experiment is being conducted to validate aerodynamic modeling methods 
and data for upset conditions which include conditions beyond the normal flight envelope. These conditions include 
stalls and post-stall departures from controlled open-loop pilot flight at high angles of attack and sideslip with high 
angular rates. The GTM-GF is scheduled to support flight testing activities in Spring 2006. Subsequently, the 
GTM-GF will be configured for testing automatic closed-loop control research systems that are being developed to 
prevent vehicle upset as a result of failures, or recover the vehicle from abnormal flight conditions. 
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